Load balancing for a cloud-based wi-fi controller based on local conditions

ABSTRACT

Load balancing for cloud-based monitoring of Wi-Fi devices on local access networks is based on local conditions. Requests for connection are received from Wi-Fi devices of the plurality of WLANs exceed a threshold. An indication of at least one condition for each of the WLANs is also received either with the connection request or separately. Example conditions include, without limitation, a number of local connections, network security breaches, guaranteed service levels, local latency or congestion, power outages or reboots, and the like. In response, at least one Wi-Fi device is prioritized and scheduled based on a corresponding at least one condition.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority as acontinuation-in-part to U.S. application Ser. No. 14/813,076, filed Jul.29, 2015, entitled DIRECTED STATION ROAMING IN CLOUD MANAGED WI-FINETWORK, by Anil KAUSHIK and claims the benefit of priority to U.S.Application Nos. 62/098,287, filed Dec. 30, 2014, entitled LOADBALANCING FOR CLOUD-BASED MONITORING OF DEVICES ON LOCAL ACCESSNETWORKS, by Maria Valavan SAVARIMUTHU, et al. and 62/099,126, filedDec. 31, 2014, entitled SELF-PROVISIONING IN WI-FI NETWORKING WITH SDN(SOFTWARE-DEFINED NETWORKING) CONTROLLERS USING PREDICTIVE TRAFFIC LOADSIN A WIRELESS COMMUNICATION NETWORK, by Anil KAUSHIK, the contents ofeach being hereby incorporated by reference in their entirety.

FIELD OF THE INVENTION

The invention relates generally to computer networking, and morespecifically, to load balancing for cloud-based monitoring of devices onLANs based on local conditions.

BACKGROUND

WLANs (wireless local access networks) experience rapidly changingconditions that can require constant monitoring. Cloud-based services,such as mCloud by Meru Networks of Sunnyvale, Calif., monitor conditionson a WLAN and provide easy access to the information without a directconnection to the WLAN. Furthermore, analytics can recognize certainconditions within the WLAN that require immediate attention, therebytriggering alerts to a network administrator.

Problematically, the cloud-based monitoring services can receiveconnection request from thousands of devices among thousands of WLANs,at the substantially the same time. The monitoring connections from asingle WLAN device can be periodically every 10 seconds, or asconfigured. If a thousand devices are on the same reporting cycle,processing power of the monitoring service or network bandwidth can beoverwhelmed, and the device may fail.

What is needed is a robust technique for load balancing for acloud-based Wi-Fi controller managing and monitoring devices on localaccess networks, based on conditions within the local network.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings, like reference numbers are used to refer tolike elements. Although the following figures depict various examples ofthe invention, the invention is not limited to the examples depicted inthe figures.

FIG. 1 is a high-level block diagram illustrating a system to loadbalance for a cloud-based Wi-Fi controller, according to one embodiment.

FIG. 2 is a more detailed block diagram illustrating a WLAN of FIG. 1that is assigned slots in load balancing among numerous WLANs, accordingto one embodiment.

FIG. 3 is a more detailed block diagram illustrating the cloud-basedWi-Fi controller of FIG. 1, according to an embodiment.

FIG. 4 is a flow chart illustrating a method for load balancing forcloud-based monitoring of devices, according to one embodiment.

FIG. 5 is a more detailed flow chart illustrating a step of loadbalancing from FIG. 4, according to one embodiment.

FIG. 6 is a block diagram illustrating an exemplary computing device,according to one embodiment.

SUMMARY

The shortcomings of the prior art are addressed by methods,(non-transitory) computer program products, and systems for loadbalancing for cloud-based monitoring of devices on local access networksbased on local conditions, as described herein.

In an embodiment, requests for connection are received from Wi-Fidevices of the plurality of WLANs. The number of connection requestswithin a time period exceeds a threshold. An indication of at least onecondition for each of the WLANs is also received either with theconnection request or separately. Example conditions include, withoutlimitation, a number of local connections, network security breaches,guaranteed service levels, local latency or congestion, power outages orreboots, and the like.

In response, at least one Wi-Fi device is prioritized based on acorresponding at least one condition. Future connections are thanscheduled based on the prioritizing. Monitoring data from the Wi-Fidevice in accordance with the scheduling and an action can be performedwith respect to operation of the Wi-Fi device on a corresponding WLANbased on the monitoring data.

Advantageously, the cloud-based Wi-Fi controller service can reliablyprovide necessary actions for monitoring and management even when anumber of connection requests exceeds capacity.

DETAILED DESCRIPTION

Methods, (non-transitory) computer program products, and systems forload balancing for cloud-based monitoring of devices on local accessnetworks based on local conditions, are described. The embodimentsherein are set forth for illustration of techniques that can beimplemented in many other embodiments not specifically detailed herein,merely for the sake of simplicity.

I. Systems to Load Balance for Cloud-Monitoring of Devices (FIGS. 1-3)

FIG. 1 is a high-level block diagram illustrating a system to loadbalance for a cloud-based Wi-Fi controller 110, according to oneembodiment. The system 100 includes a cloud-based Wi-Fi controller 110and WLANs 120A-120N coupled to a network 199. The components can beimplemented in hardware, software, or a combination. The system of FIG.1 is just an example of numerous other possible embodiments having moreor less WLANs.

The cloud-based Wi-Fi controller 110 manages and monitors networkactivity for Wi-Fi devices on each of the WLANs 120A-120N. A loadbalancer 112 of the cloud-based Wi-Fi controller 110 manages connectionsfor up to thousands of Wi-Fi devices (Wi-Fi devices refer to any deviceassociated with the Wi-Fi portion of a WLAN including local controllers,access points, and stations) attempting to connect, as described furtherbelow. More specifically, one embodiment determines a volume ofconnections (e.g., thousands of devices) and assigns groups ofconnections to a particular slot within a particular period of time.Volume of connections can be actual, preconfigured, or predicted.Various algorithms can be implemented. In one implementation, eachconnection is treated equally. In another implementation, prioritiesvary with local controllers having the highest priority, access pointshaving the next highest priority, and stations having the lowestpriority. Other embodiments take additional factors into account. Forexample, local time on devices, latency between devices and the Wi-Ficloud monitor 112, number of critical events occurring on devices,number of stations connected to devices, and the like. Many otherfactors are possible and other factors are discussed herein. Onceconnection slots are determined, the load balancer 112 can send a newtag to devices indicating a local time to send data and an intervallength in a period. Some connection sockets can be reserved forconnections outside of the algorithm. Different sets of connectionsockets can be subject to different algorithms.

In one embodiment, the load balancer 112 manages connections based onlocal Wi-Fi conditions on an individual WLAN. Frames initially sent in aconnection request to the cloud-based Wi-Fi controller 110 for Wi-Fidevices can include fields for certain Wi-Fi conditions. Fields can bewithin headers or pre-configured parts of the data field. Examples ofconditions include, but are not limited to, number of stations connectedto an access point, number of access points, amount of local Wi-Ficongestion or interference, subscription tier of entity, number ofinstances running on the cloud-based Wi-Fi controller 110, and the like.WLAN devices connect to report data either synchronously (e.g.,periodically) or asynchronously (e.g., responsive to triggeringconditions). The information can be stored by the cloud-based Wi-Ficontroller 110 per device, per WLAN, per entity, per geographic region,or according to various analytics.

In an embodiment, there can be more than one instance of the cloud-basedWi-Fi controller 110, and each can separately schedule connections.Separate instances can run on different physical servers, on differentprocessors of a common device, on different threads of a commonmulti-threaded processor, or on different virtual machines.

A network administrator, user, or program process can log-on to getinformation about how many devices are connected, performance, downtime,latency, and other parameters. Information can also be pushed,particular, when thresholds are exceeded and trigger alerts. Thecloud-based Wi-Fi controller 110 is discussed in more detail below withreference to FIG. 3.

The WLANs 120A-120N can be operated by different entities or the sameentity, and include various combinations of devices that report to thecloud-based Wi-Fi controller 110 as regulated by the load balancer 112.One example of FIG. 2 shows a more detailed block diagram illustrating aWLAN of FIG. 1 that is assigned slots in load balancing among numerousWLANs. WLAN 120A comprises a local Wi-Fi controller 210, an SDN(software-defined networking) controller 220, access points 230A-230B,and stations 250A-250C, each of which can individually connect with thecloud-based Wi-Fi controller 110. In other embodiments, the local Wi-Ficontroller 210 and/or the SDN controller 220 can collectively reportdata. In one embodiment, each device individually connects to thecloud-based Wi-Fi controller 110, and in a second embodiment, one or agroup of representative (e.g., access points 230A-230B) connects withaggregate info that is locally collected. The WLAN components are merelyan example of many possible configurations which could include more orless access points, controllers, stations, and can also include wellknown components such as routers, switches, and firewalls. Also, WLANs120B and 120N can have different configurations based on entity needs.

The local Wi-Fi controller 210 (e.g., an MC1500 or MC6000 device by MeruNetworks/Fortinet Inc. of Sunnyvale, Calif. as described in U.S.application Ser. No. 13/426,703 filed Mar. 22, 2012, now issued U.S.Pat. No. 9,215,754 and commonly-assigned) provides centralizedmanagement for the access points 230A-230B. The local Wi-Fi controller210 can provide many other services to the network 199 such as virtualcell and virtual port functionalities (see further description in U.S.application Ser. No. 13/426,703, which is hereby incorporated byreference). The access points 230-230B can be an AP 110 or AP 433(modified as discussed herein) by Meru Networks of Sunnyvale, Calif.Each access point 230A-230B is preferably connected to the LAN 101(e.g., gateway, switch, router, hub, or another access point that isconnected to the network 199) via a wired connection, but in someembodiments, such as a mesh network, the uplink connection is wireless.

The access points 230-230B can be set-up in various configurations toprovide wireless coverage areas for stations to have external networkaccess. In another embodiment, the functionality is incorporated into aswitch or router.

The stations 240A-240C can be, for example, a personal computer, alaptop computer, a tablet computer, a smart phone, a mobile computingdevice, an Internet appliance, a non-wireless device modified to havewireless capabilities, or any other appropriate processor-drivencomputing device. A station is wirelessly coupled to an access point.Many other types of devices, under many other types of configurationscan connect to the cloud-based Wi-Fi controller 110.

FIG. 3 is a more detailed block diagram illustrating the cloud-basedWi-Fi controller 110 of FIG. 1, according to an embodiment. Thecloud-based Wi-Fi controller 110 comprises the load balancer 112, a useraccount module 340, an access point manager 350 and a station manager360. Additional components are components utilized for normal operationsthat are not germane to the techniques described herein are present butnot shown.

The load balancer 112, in turn, comprises a local Wi-Fi conditionsmodule 210, a connection priority module 210 and a scheduling engine330. The local Wi-Fi conditions module 210 determines what is going oncurrently and historically with devices connected to the Wi-Fi, such asaccess points and stations. In one embodiment, aggregate network metricsare submitted via connection request frames sent during a periodicconnection. In another embodiment, specific condition frames are sentfrom a daemon or other software module executing on an access point orother part of a WLAN for collecting network metrics. In still anotherembodiment, specific conditions are by individual devices including eachaccess point and each station. The local Wi-Fi conditions module 310 canextract information from incoming frames for storage in a database. Datacan be stored on a per-WLAN, per-entity, per-access point, orper-station bases, for example.

The connection priority module 310 accesses the database to determinewhether a default priority for a connection request should be modified.In one example, default priority is set to 0 and moves in the positivedirection (e.g., +1, +2, etc.) to increase priority and in the negativedirection (e.g., −1, −2, etc.) to decrease priority. In another example,conditions are weighted relative to importance on prioritydetermination, such as emergency conditions (e.g., security alert) andsudden traffic volatility relative to a new station joining a WLAN ofmany stations. Subscription modules can also have an effect to allowhigher paying customers to be given better service. Prioritydeterminations and updates can be stored in the same database asconditions or separately. Many other configurations are possible.

The scheduling engine 330 uses the priority determinations as an inputfor scheduling connections. In one embodiment, priority is the onlyinput. The scheduling engine 330 can assign tokens to a Wi-Fi devicethat presents the tokens for access. In another implementation, timeslots are assigned for synchronized access. The local time of a deviceand latency between the cloud and device are taken into account in somenon-limiting embodiments. Also, asynchronous requests can be grantedon-the-fly with conflicts resolved from priority determinations.

An example of a default scheduling for even distribution can bedetermined by taking the capacity of an instance of the cloud-basedWi-Fi controller 110 of 100 connections per second and allow a total of1,000 connecting devices to connect once every 10 seconds. The first 100devices connect the first second, the second 100 devices connect thesecond second, and so on until the first 100 devices connect againduring the eleventh second. The described modifications based onpriority can be calculated and applied. As a result, a higherprioritized 100 devices may be given access the first second and againduring the fifth second and every five seconds thereafter, and the other900 devices filling in the available seconds in between. Anothermodification includes a WLAN entering a scheduled high usage period inwhich corresponding devices are elevated to the top 100 while otherdevices are dropped from the top 100. An embodiment, switches modes outof the default scheduling upon detection that a current amount ofconnection request exceeds the capacity for total connection capacity atthe same time. One of ordinary skill in the art will recognize thecountless other possible algorithms for implementation.

The user account module 340 allows an administrator or other entityrepresentative to log on and see a snapshot of conditions for aparticular WLAN. When the cloud-based Wi-Fi controller 110 is utilizedin a SaaS (software as a service) model, multiple entities are served,so individual accounts with passwords are necessary. Each account can beconfigured by registering Wi-Fi devices for communication.

The access point manager 350 of an embodiment manages one or more accesspoints for a particular entity. For example, BSSIDs (basic service setidentifiers) can be assigned, station handoffs between access points areconfigured at different access points, and the like. In one case, aseamless mobility service uses a common BSSID across several accesspoints and manages which access point should respond to a particularstation on that WLAN. Priority can be adjusted based on seamlessmobility services and current conditions.

The station manager 360 of an embodiment manages one or more stationsfor a particular entity, or for a particular access point being managed.One implementation of virtual port services assigns a unique BSSID toeach station for individual management of the connection (e.g., policy,uplink speed, permissions, etc.). When handing off a station from oneaccess point to another access point using the virtual port service, theunique BSSID is moved from being handled by one access point to anotheraccess point. Priority for an access point or a particular station canbe adjusted based on virtual port services and current conditions.

II. Methods for Load Balancing for Cloud-Monitoring of Devices (FIGS.4-5)

FIG. 4 is a flow chart illustrating a method 400 for load balancing forcloud-based monitoring of devices, according to one embodiment. One ofordinary skill in the art will recognize that the method 400 isnon-limiting as other embodiments can have more or less steps and can beperformed in a different order.

A plurality of WLANS are configured for management and monitoring by acloud-based Wi-Fi controller (step 410). If the connection requests fromWLANs exceed a preconfigured threshold (step 420), in the presentembodiment, the WLANS and associated Wi-Fi devices are load balanced byprioritizing scheduled connection requests based on local conditions(step 430) (as discussed in more detail below in association with FIG.5). An action related to the WLAN is performed based on the connection(step 440). For example, an alert may be sent to an administrator orvirtual port services can be temporarily suspended.

FIG. 5 is a more detailed flow chart illustrating the step 430 of loadbalancing from FIG. 4, according to one embodiment.

Connection requests are received from Wi-Fi devices on WLANs along withlocal conditions of the WLANs (step 510). The local conditions areextracted and analyzed. The Wi-Fi devices are prioritized based on thelocal conditions (step 520). Future connections are scheduled based onthe prioritizing (step 530). Monitoring data from the Wi-Fi device isreceived and stored in accordance with the scheduling. In some cases,monitoring data is the same, similar, or a part of local conditions.

III. Generic Computing Device (FIG. 6)

FIG. 6 is a block diagram illustrating an exemplary computing device 600for use in the system 100 of FIG. 1, according to one embodiment. Thecomputing device 600 is an exemplary device that is implementable foreach of the components of the system 100, including cloud-based Wi-Ficontroller 110, the local Wi-Fi controller 210, the SDN controller 220,the access points 230A, 230B, and the stations 240A-240C. The computingdevice 600 can be a mobile computing device, a laptop device, asmartphone, a tablet device, a phablet device, a video game console, apersonal computing device, a stationary computing device, a serverblade, an Internet appliance, a virtual computing device, a distributedcomputing device, a cloud-based computing device, or any appropriateprocessor-driven device.

The computing device 600, of the present embodiment, includes a memory610, a processor 620, a storage drive 630, and an I/O port 640. Each ofthe components is coupled for electronic communication via a bus 699.Communication can be digital and/or analog, and use any suitableprotocol.

The memory 610 further comprises network applications 612 and anoperating system 614. The network applications 612 can include themodules of the components illustrated in FIGS. 1-4. Other networkapplications 612 can include a web browser, a mobile application, anapplication that uses networking, a remote application executinglocally, a network protocol application, a network managementapplication, a network routing application, or the like.

The operating system 614 can be one of the Microsoft Windows® family ofoperating systems (e.g., Windows 65, 68, Me, Windows NT, Windows 2000,Windows XP, Windows XP x64 Edition, Windows Vista, Windows CE, WindowsMobile, Windows 6 or Windows 8), Linux, HP-UX, UNIX, Sun OS, Solaris,Mac OS X, Alpha OS, AIX, IRIX32, or IRIX64. Other operating systems maybe used. Microsoft Windows is a trademark of Microsoft Corporation.

The processor 620 can be a network processor (e.g., optimized for IEEE802.11), a general purpose processor, an application-specific integratedcircuit (ASIC), a field programmable gate array (FPGA), a reducedinstruction set controller (RISC) processor, an integrated circuit, orthe like. Qualcomm Atheros, Broadcom Corporation, and MarvellSemiconductors manufacture processors that are optimized for IEEE 802.11devices. The processor 620 can be single core, multiple core, or includemore than one processing elements. The processor 620 can be disposed onsilicon or any other suitable material. The processor 620 can receiveand execute instructions and data stored in the memory 610 or thestorage drive 630

The storage drive 630 can be any non-volatile type of storage such as amagnetic disc, EEPROM, Flash, or the like. The storage drive 630 storescode and data for applications.

The I/O port 640 further comprises a user interface 642 and a networkinterface 644. The user interface 642 can output to a display device andreceive input from, for example, a keyboard. The network interface 644(e.g. RF antennae) connects to a medium such as Ethernet or Wi-Fi fordata input and output.

Many of the functionalities described herein can be implemented withcomputer software, computer hardware, or a combination.

Computer software products (e.g., non-transitory computer productsstoring source code) may be written in any of various suitableprogramming languages, such as C, C++, C#, Oracle® Java, JavaScript,PHP, Python, Perl, Ruby, AJAX, and Adobe® Flash®. The computer softwareproduct may be an independent application with data input and datadisplay modules. Alternatively, the computer software products may beclasses that are instantiated as distributed objects. The computersoftware products may also be component software such as Java Beans(from Sun Microsystems) or Enterprise Java Beans (EJB from SunMicrosystems).

Furthermore, the computer that is running the previously mentionedcomputer software may be connected to a network and may interface toother computers using this network. The network may be on an intranet orthe Internet, among others. The network may be a wired network (e.g.,using copper), telephone network, packet network, an optical network(e.g., using optical fiber), or a wireless network, or any combinationof these. For example, data and other information may be passed betweenthe computer and components (or steps) of a system of the inventionusing a wireless network using a protocol such as Wi-Fi (IEEE standards802.11, 802.11a, 802.11b, 802.11e, 802.11g, 802.11i, 802.11n, and802.11ac, just to name a few examples). For example, signals from acomputer may be transferred, at least in part, wirelessly to componentsor other computers.

In an embodiment, with a Web browser executing on a computer workstationsystem, a user accesses a system on the World Wide Web (WWW) through anetwork such as the Internet. The Web browser is used to download webpages or other content in various formats including HTML, XML, text,PDF, and postscript, and may be used to upload information to otherparts of the system. The Web browser may use uniform resourceidentifiers (URLs) to identify resources on the Web and hypertexttransfer protocol (HTTP) in transferring files on the Web.

IV. Additional Embodiments

Generally, one of ordinary skill in the art will recognize that theexamples set forth herein are non-limiting and only illustrative ofwidely-applicable principles. Accordingly, this description of theinvention has been presented for the purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise form described, and many modifications andvariations are possible in light of the teaching above. The embodimentswere chosen and described in order to best explain the principles of theinvention and its practical applications. This description will enableothers skilled in the art to best utilize and practice the invention invarious embodiments and with various modifications as are suited to aparticular use. The scope of the invention is defined by the followingclaims.

We claim:
 1. A computer-implemented method for load balancing in acloud-based Wi-Fi controller device that remotely monitors Wi-Fi devicesfor a plurality of WLANs (wireless local access networks), the methodcomprising the steps of: receiving requests for connection from Wi-Fidevices of the plurality of WLANs, wherein the number of connectionrequests within a time period exceeds a threshold; receiving anindication of at least one condition for each of the WLANs; prioritizingat least one Wi-Fi device based on a corresponding at least onecondition; scheduling future connections based on the prioritizing;receiving monitoring data from the Wi-Fi device in accordance with thescheduling; and performing at least one action with respect to operationof the Wi-Fi device on a corresponding WLAN based on the monitoringdata.
 2. The method of claim 1, wherein the number of connectionrequests within a time period exceeds a total capacity of connectionrequests
 3. The method of claim 1, wherein the local conditions compriseat least one from the group of: a number of local connections, type ofWi-Fi device, a vulnerability detection, an intrusion detection, a roguedevice detection, a power outage, a reboot, local latency, localcongestion, and a change in a local condition surpassing a threshold. 4.The method of claim 1, wherein the prioritizing is based on a servicetier of an entity associated with the Wi-Fi device.
 5. The method ofclaim 1, further comprising: receiving a local time of the Wi-Fi device;receiving a flight time between the Wi-Fi device and the cloud-basedWi-Fi controller; calculating a dispatch time for a connection requestusing the local time and the flight time; and sending the dispatch timeto the Wi-Fi device.
 6. The method of claim 1, wherein the receivedmonitoring data is used as the indication of at least one condition forscheduling latter connections.
 7. The method of claim 1, furthercomprising: activating a load balancing mode responsive to the number ofrequests within the time period exceeding the threshold.
 8. The methodof claim 1, further comprising: spawning more than one cloud-based Wi-Ficontroller instance, wherein load balancing considers available connectsacross the more than one cloud-based Wi-Fi controller instance.
 9. Themethod of claim 1, wherein the Wi-Fi device operates according to atleast one of IEEE 802.11n, IEEE 802.11 ac wave 2, and a Wi-Fi protocolthat supports beamforming.
 10. A non-transitory computer-readable mediumstoring source code that, when executed by a processor, performs amethod load for balancing in a cloud-based Wi-Fi controller device thatremotely monitors Wi-Fi devices for a plurality of WLANs (wireless localaccess networks), the method comprising the steps of: receiving requestsfor connection from Wi-Fi devices of the plurality of WLANs, wherein thenumber of connection requests within a time period exceeds a threshold;receiving an indication of at least one condition for each of the WLANs;prioritizing at least one Wi-Fi device based on a corresponding at leastone condition; scheduling future connections based on the prioritizing;receiving monitoring data from the Wi-Fi device in accordance with thescheduling; and performing at least one action with respect to operationof the Wi-Fi device on a corresponding WLAN based on the monitoring data11. A cloud-based Wi-Fi controller device that load balances whileremotely Wi-Fi devices for a plurality of WLANs (wireless local accessnetworks), the cloud-based Wi-Fi controller comprising: a processor; anda memory, storing: a first module to receive requests for connectionfrom Wi-Fi devices of the plurality of WLANs, wherein the number ofconnection requests within a time period exceeds a threshold; a secondmodule to receive an indication of at least one condition for each ofthe WLANs; a third module to receive at least one Wi-Fi device based ona corresponding at least one condition; a fourth module to schedulefuture connections based on the prioritizing; a fifth module to monitordata from the Wi-Fi device in accordance with the scheduling; and asixth module to perform at least one action with respect to operation ofthe Wi-Fi device on a corresponding WLAN based on the monitoring data.